home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0257.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  2.5 KB  |  45 lines
  1. Dan's comments are right on the money.  As an example of how you can
  2. treat non-mail-oriented data as being in MIME format, I've recently
  3. written a script that makes it trivial to set up a MIME-smart mailserver
  4. daemon for, say, everything in your anonymous ftp directory.  This
  5. script -- which will be part of the next metamail release -- accepts
  6. mail requests that give path names relative to the anonymous ftp root,
  7. e.g. "pub/nsb/BodyFormats.txt" and sends the results back as MIME-format
  8. mail.  The neat thing is that the files themselves don't need to be in
  9. MIME format.  The files are assumed to be plain text unless there is a
  10. ".ct" file (e.g. "pub/nsb/BodyFormats.txt.ct") in which case that file
  11. is assumed to contain the Content-type information.  Thus if you have a
  12. gif image in file "foo", you can put the text "image/gif" in the file
  13. "foo.ct" and the mailserver will be ready to send the GIF image as
  14. MIME-format mail.  The script is smart enough, using the metamail tools,
  15. to deal with any necessary encoding for mail transport, even though the
  16. raw data is unencoded.
  17.  
  18. The point is that, as Dan says, the data doesn't need to be explicitly
  19. in MIME format.  MIME body parts are just (possibly encoded) data in
  20. reasonably standard formats.  If you don't enclose it in a mail-ish
  21. thing with a content-type header field, you need some other
  22. "out-of-band" way of providing the type information, but this can be
  23. done in many ways, e.g. the ".ct" files my mailserver uses.  Viewed this
  24. way, all that MIME is really comes down to three things:
  25.  
  26. 1.  A mechanism for encoding arbitrary data for mail transport.  This is
  27. orthogonal to the other parts and can be largely ignored in non-mail
  28. applications.
  29.  
  30. 2.  A mechanism for combining multiple objects in a "multipart" format
  31. defined by MIME.  This doesn't need to be used by non-mail applications,
  32. but a common way of doing this has obvious value.  Why shouldn't
  33. multi-media objects be shared across email, wais, gopher, and www?
  34.  
  35. 3.  A naming convention and a set of standard names for describing data
  36. types such as "image/gif" and "audio/basic".  The common naming
  37. conventions are perhaps the most valuable aspect of MIME for non-mail
  38. applications, as it is pretty obviously silly to give slightly different
  39. names to the same things in different systems.
  40.  
  41. Anyway, as a principle author of MIME I know I'm not in a great position
  42. to appear to be objective, but I really don't see any good reasons not
  43. to use MIME in applicaitons such as gopher, wais, or www.  -- Nathaniel
  44.  
  45.